A form on a World Wide Web (“Web”) page mimics the usage of paper forms by allowing a user to enter data that is sent to a server for processing. For instance, a form may be utilized to enter name and address information on an e-commerce Web site. In order to use such a form, a user typically utilizes a computer mouse or other pointing device to place an insertion point into the fields of the form. Then, with a keyboard or other text input device, the user inputs text data into the form fields. Often, a button or other object will be displayed that the user actuates to post the inputted form data to the computer hosting the Web site.
Because of the stateless nature of most Web servers, a client computer can send form data to a Web server without having previously requested the form. For instance, if form data is posted to a Web server in a format that the server expects, the server will accept the data without first having sent the corresponding form. Because the server does not keep track of what it previously sent to each client computer, the Web server will accept the posted form data even though it had not previously transmitted the form to the sending client. This is referred to as “cross-site” posting.
An attacker with malicious intent can exploit cross-site posting to trick a user into unknowingly posting information to a Web site. For example, an attacker may induce a user to actuate a hypertext link, such as by sending an e-mail to the user that includes the link. By actuating the link, a user may unknowingly cause a script to be executed that posts data to a Web site. These attacks are often referred to as Cross-Site Request Forgery (“CSRF”) attacks because they only require an authorized user to click on a hyperlink in order to post the embedded command to a Web server. By clicking the hyperlink, the user is unknowingly posting information to the Web server.
Some safeguards are available to prevent CSRF attacks. For example, one type of safeguard causes a Web server to refuse to accept form data posted after a predetermined period of time has elapsed since the form page was transmitted from the server. This type of safeguard, however, can be frustrating to users in several scenarios. For instance, if a user takes too long to fill out a form, the form will expire and the server will reject the form when it is finally posted. This can be especially frustrating for users if inputted form data is lost as the result of an expired form page.
It is with respect to these considerations and others that the disclosure made herein is provided.